Many of today's communication systems using Internet appliances, cell phones, portable computers and other systems, such as computer networks, telecommunication systems and other systems are increasingly employing digital signature technology to allow units that are communicating within the system to digitally sign data so that a receiver can verify that the data was in fact sent by a sender purporting to be the originator. One well known type of system is a public/private key system that incorporates a digital signature key pair as known in the art. In such systems, a public signature key is known to any participants in the community, and a secret private digital signature key is assigned to each subscriber, such as a software application, a computer terminal, or other entity. Industry standards have developed for electronic mail (e-mail) servers that route e-mails, through a store-and-forward manner, among members of the communication system community. Such store-and-forward based communication typically uses for example, a MIME format, as known in the art. In such systems, a user must typically initiate a digital signature process. As such, when text data is sent by an e-mail server or by an originator, the user must manually request and add a digital signature to the information which may then be communicated to another communication unit for verification.
However, increasingly, transactions requiring interactive, generally real time, bi-directional communication, including text and non-text information need to be facilitated over worldwide networks and intra-networks, such as systems that employ the use of markup language data. For example, a common markup language used on the Internet is the hypertext markup language (HTML) which is a format used to digitally describe just about everything in the document that is not content. This is sometimes referred to as formatting data. With conventional markup language servers, such as WEB servers, a browser program or other interfaces do not generally include digital signature engines for interactive communications using for example, markup language based data. Typically when a system does include a digital signature engine of some sort, each interface manufacturer typically has its own format for an inclusion of a transaction based digital signature. However, there is no standardized methodology for utilizing digital signatures with formatting data. For example a conventional web server typically needs to maintain a set of digital signature request forms for different types of browsers if a single server needs to communicate with multiple different units within a community not containing the same browser. Although systems are known to have form or markup language based digital signature capability, the requirement of maintaining multiple signature request forms for each different type of browser can unnecessarily increase the overhead of a browser or web server. Also, it would be desirable to have a system and method that allowed the facility to incorporate form-based digital signature communication with browsers or interfaces that do not have digital signature engines. As different web server formats are developed, and as communication systems grow with users having different types of browsers or browsers with no digital signature capabilities, it would desirable to allow non-repudiation of information to be independent to the type of browser or interface used by a subscriber or software application.
Some browsers are known which include an integrated digital signature generator for form based data that utilizes signature initiation data embedded in a subset of data to be signed. The digital signature generator is integrated in the sense that the signature generator uses the same address space as the browser. In one such system, a persistent digital signature is generated so that verification of a signor may be performed after a transaction has occurred. However, such systems typically only sign a portion or subset of the data presented to the user. As such, these systems do not generally provide an accurate record of what the user actually agreed upon. Such systems are typically dedicated to a particular type of web server or a particular type of browser. Therefore an increase in cost and processing overhead occurs when a web server must interface with browsers having differing digital signature engines. A digital signature plug in for each different type of browser may typically be required.
Also, as is known in the art, proxies are typically used in communication systems for transferring data, such as markup language data between a web server for example and a plurality of browsers. For example, a web proxy is typically a program on a server that redirects information and may provide such capabilities such as caching of information, and authentication of signatures. The proxies generally serve as an intermediate protocol handle. By way of example, an HTTP proxy looks at every header in a form to determine what packets are directed to which proxy address.
Also, it is conventional to have digital signature engines in each proxy to allow the digital signing of information that is sent during each data unit transfer session for determining whether information was corrupted during the transfer. For example a single transaction may require communication of multiple data units of information. The length of a data unit may be set by way of an industry standard such as in the case of the Internet. However any suitable data unit length may be used. The digital signatures for each data unit are discarded upon completion of a transaction and it can take multiple data units to get one form communicated. The data unit digital signatures are generated by the proxies to ensure that information was not modified during transmission. The digital signatures are stripped off below the application level so there is no digital signature on the form (e.g., HTTP form) when it is used by an application for example. There is no “persistence” of the signature, since they are used for session integrity only. In conventional systems employing digital signatures during data unit communication, the digital signature is applied by a server proxy for example so that a browser proxy may receive the signed data and verify the integrity of the data. These digital signatures are then discarded prior to the data being sent to the application or browser requesting the information. As such, data unit digital signature engines are used to ensure that data unit information can be checked for integrity. However, subsequent authentication of the information for the entire transaction is typically not used.
On line electronic transactions require proof of a transaction after a transaction has occurred. For example, if a legal contract or bank transaction occurred and there is a dispute at a later time, it would be desirable to use the electronic transaction documentation in a court of law or arbitration setting to avoid repudiation of the transaction by one of the parties to the transaction. Accordingly, digital signatures are often used to uniquely associate a user with a particular document. As noted above, mark up language forms are often used on the Internet to allow users to purchase goods and services on line as well as performing banking transactions and other contractual transactions. Conventional Web browsers typically only use digital certificates for encryption purposes and not for providing digital signatures. In addition, Web browsers are known to interface with cryptographic applications to allow digital signature of data entered by a user into a form. However, as noted above, the form format itself is typically not digitally signed thereby allowing a potential hacker to modify the form format, including displayed field names or other information after a transaction has been executed. Typically, mark up language forms include hidden name attributes (hidden field names), associated field names that are displayed to a user and data entry fields to allow a user to enter data associated with the displayed field name. In addition, form formatting information, such as the fonts, colors, type sizes and other form formatting information is also typically included in mark up language forms. However, known Web browsers typically only sign the hidden “name” attribute of an HTML form input field and the user input information after a user has completed a form for a transaction. Conventional Web browsers typically do not sign the form formatting information, namely the text that is actually displayed to the user, but signs the hidden field names. This information has an effect on the semantics of the data, and hence, there may be different meanings associated with what the user signed and what they viewed on their browser.
Other systems are being developed that allow a digital signing process to sign everything that is actually displayed to a user when the user indicates that he or she has accepted the terms of the transaction or has filled out all the requisite form fields to complete a transaction. These applications are Web-browser based and typically require separate form software. It would be desirable to allow the Web browser to have non-repudiation of Web forms and avoid the need for separate forms each time a transaction has to occur. Accordingly, it would be desirable to have browser-rendered forms to be used in transactions.
A typical sequence of communication for a transaction may be as follows. In the context of an Internet transaction, for example, a user may log on to a home page of an on-line seller. The on-line seller's server (receiving unit) transmits an incomplete HTML form to the user's browser. The user then completes the form by entering the requisite information and clicks on a “submit” button to indicate that the user has completed the transaction. A Web server then sends a detailed summary of the transaction data back to the user to get confirmation that the user agrees to the terms of the transaction. For example, the server may then examine the contents of the completed form and add confirmation data, such as a Web server digital signature, date, time or any other information. The confirmed HTML form is then sent back to the user for final confirmation. The user is able to review the details of the transaction, and may then provide final confirmation by selecting a “accept” button presented through the Web browser. A cryptographic application may then digitally sign the accepted confirmation request information which may include both the visible (displayed) and nonvisible (hidden) form information, namely the user input information, the field names on the form, and the form formatting information. The confirmation information is then sent back to the Web server for final processing and the transaction is complete. However, such systems may require both a client and Web server proxy program when the client proxy interfaces with the Web browser. The client proxy acts as a cryptographic application that signs the user entered data, field name and form formatting information. The Web server digitally signs the form formatting data when it requests confirmation from the user. Such a system typically requires software installation both for every client and in the Web server. This can result in expensive deployability problems, particularly where large numbers of clients wish to use the system.
Accordingly, a need exists for a suitable work up language based non-repudiation method and apparatus.